Method of treating hair

ABSTRACT

There is described a method for enabling a user of a client computer to securely access a remote server via a network, which is preferably the Internet, by authenticating the user. The method comprises providing a portable apparatus to the user which may communicate with the client computer. It further involves storing on the portable apparatus user credentials required to enable the user to be authenticated at the server and performing an authentication protocol between the client and the server. The authentication protocol includes the transmission to the server of a digest based at least partially on the user credentials; and the user credentials are stored on the portable apparatus in the form of a digest.

The present invention relates to an apparatus and method for a user toauthenticate himself when logging on to a computer, such as a remoteserver that is accessed via the Internet. In particular, the inventionrelates to the use of such a method and apparatus for digest accessauthentication.

The use of a username and password to log on to computer systems,whether local or remote, has become ubiquitous in the modern age. Inbasic access authentication, the username and password are sent in plaintext, which is satisfactory for a secure system, but in the case of aninsecure network there is a risk that the password could be interceptedand so protocols have been developed to overcome this problem. Onewell-known approach, which is widely used for access to web sites, isdigest access authentication where a “digest”, such as a hash function,of the password is transmitted over the network.

HTTP Digest Access Authentication is a 1997 web standard forauthenticating a client to a server. Its intended use is on the WorldWide Web, but it is perfectly implementable on local resources, or inany situation where resource access over HTTP should be restricted.Digest authentication was introduced as an extension to the formerstandard basic access authentication which, as noted above is consideredinsecure.

In practice, digest authentication is used to enforce an access controlpolicy on a certain realm and the resources it contains. Each user mustbe registered with sufficient credentials (user name and password) atthe system enforcing the realm's access control and be able toauthenticate himself to the server using those registered credentials.

When a user attempts to access a particular realm, for example,http://example.com/secret/, the client's web browser (user agent) issuesan HTTP GET http://example.com/secret/request. The server then respondswith a 401 Authorization Required status code, indicating to the userthat this resource requires him to be authorized for access, and awww-authenticate header, containing information that can help the systemcalculate the correct response for the server. The web browser thenprompts the user for user name and password. A combination of thesecredentials and information extracted from the incoming www-authenticateheader are hashed and then passed to the server in an Authorizationheader appended to another HTTP GET request. The server receives theresponse value—a hash of the user's credentials and the name of theprotection realm. As hashing algorithms are one-way functions, there isno way for an adversary to simply extract the passwords from the value.At the server side, the credentials that were stored locally at the timeof registration are used to calculate another hash value by the samerules and algorithm as at the client side. If the server sidecalculation is equivalent to the one received from the client, theserver can conclude that it is certain of the client's identity andvalidate it against the access policy. If the user is authenticated andauthorized, the server responds with a 200 OK status code and thecontents of the protected resource that the user requested.

In addition to cryptographic hash functions, several other securitymechanisms were introduced with Digest Access Authentication. Forexample, the password hash could still be intercepted and used by ahacker to access the server. This is known as a replay attack.Countering replay attacks is done by introducing a “nonce” (number usedonly once) which is valid for only for one attempt at authenticating orfor a very limited amount of time. The nonce value is created at theserver as a challenge to the user and the user must respond with thatvalue unchanged to pass the challenge.

Further details of Digest Access Authentication are provided in Annex 1.

Digest Access Authentication is reasonably secure, but it will beappreciated that its security depends upon the user's password remainingsecret. However, it is well-known that users often use the same passwordfor multiple systems, web sites, etc., write down their password whereit may be discovered, and/or chose passwords which are easy to guess.Published lists of popular passwords include “password”, “football”,etc. and where a single password is used for multiple systems, discoveryof that one password compromises the user at each of those systems.

Ideally, therefore, a given password would only be used for one purpose,would be difficult to guess and would never be written down. However,these requirements are not well-suited to the human brain. Users may beforced to use mixtures of upper and lower case letters, digits and othercharacters. However, random strings of characters that are harder toguess are equally hard to remember and this difficulty increases withthe number of passwords that must be remembered. If such passwords areto be used, therefore, they have to be written down. This may not be aserious vulnerability in a private situation, but it increases the riskof espionage in a communal or commercial environment.

The problem of an individual being unable to remember multiplehard-to-guess passwords has been addressed by the provision of identitymanagement locally, i.e. in the user's domain, where they may be stored.

For example, web browsers provide software-based password managers wherecredentials are stored locally on the browser and entered automaticallyor on request. However, although the passwords are stored in encryptedformat, it is possible to decrypt them by means of a simple scriptwithout a key being needed, unless a master password is set. Thus, suchlocally stored credentials are vulnerable to attack by a trojan or othermalware.

Another known approach is to store passwords locally in hardware such asa secure external device. User Centric Identity Management by Simon Popeand Audun Jøsang (AusCERT Conference 2005) describes the use of aPersonal Authentication Device (PAD), a secure device external to thecomputer, such as a smart card or other portable device. The PAD is usedas an identity management system to which the user authenticates once(with a PIN number, password or similar), and for one session, the usercan authenticate to every supported service automatically using the PADas his identity manager. This is done by secure transmission ofcredentials between the PAD and the server. The PAD may be connected tothe server via client platform by a communication channel (e.g. wirelessprotocols like Bluetooth), or directly to the server via a secondarychannel. In. Identity Management by Audun Jøsang (URL:http://folk.uio.no/josang/im/) a variant called the OffPAD is described,which is so-called because it is intended to be (mostly) off-line andtherefore more secure.

According to a first aspect of the invention there is provided a methodfor enabling a user of a client computer to securely access a remoteserver via a network by authenticating the user, the method comprising:providing a portable apparatus to the user which may communicate withthe client computer; storing on the portable apparatus user credentialsrequired to enable the user to be authenticated at the server;performing an authentication protocol between the client and the server;wherein: the authentication protocol includes the transmission to theserver of a digest based at least partially on the user credentials; andthe user credentials are stored on the portable apparatus in the form ofa digest.

Thus, by means of the invention, the user credentials, are never storedor transmitted in plain text. Those credentials may comprise theusername, password of the user and realm of the server that is to beaccessed.

The invention is applicable, in principle, to any network, but it willnormally be applied to a public IP network, such as the Internet. Thus,the user of the client computer will typically be seeking to securelyaccess a remote server over the Internet. Thus, the term “remote” willnormally imply not just that the client and server are separate, butthat they are geographically distant from each other and may typicallybe operated by unrelated parties. Thus, the remote server may beproviding an on-line service, which might be information, commerce,entertainment, etc.

Although the invention is applicable to any suitable authenticationprotocol. such protocols usually involve a challenge from the server towhich the client must respond. The protocol is preferably HTTP DigestAccess Authentication because this is so widely employed, particularlyin relation to the Internet where the invention is particularly useful.Thus, the digest of credentials is most preferably a hash (such as SHA-1or MD-5) of a string comprising user name, password and server realm.e.g. the string is that conventionally referred to as A1 and its hash isthat referred to as HA1—see Annex 1. That digest may then be used togenerate a response, which is typically a further digest, using datafrom the challenge.

The data from the challenge may comprise the HTTP request method (e.g.GET) and the uniform resource indicator (URI) of the digest realm (e.g./secret/). The string comprising these is known as A2 and its hash isHA2. The response may then be a hash of A1, A2 and a nonce, e.g. MD5(HA1:nonce:HA2). This allows backwards compatibility with the firstspecification of Digest Access Authentication. However, for higherquality of protection, the response hash is also based on a noncecounter (a number starting at 00000001), a client nonce, and/or aquality of protection (qop) value. The client nonce allows the client tovalidate the server relationship later and the qop value describes whatlevel of protection should be met. Thus, the response may beMD5(HA1:nonce:nonceCount:clientNonce:qop:HA2) in line with the RFC 2617standard.

The portable apparatus could be any apparatus capable of providingstorage for the credentials, the necessary data processing capabilityand means to communicate with the client computer. As such, existingdevices such as smartphones could be used. However, this is lesspreferred because the multiplicity of communication modes provided bysuch devices increase the number of routes by which a hacking attack maytake place. A bespoke device is therefore to be preferred. Furthermore,the portable device preferably communicates with the client computeronly to facilitate authentication of the user. As such, it is primarilyoff-line and may thus be a form of “OffPAD”.

The OffPAD is preferably designed to have limited connectivity in orderto reduce its vulnerability to attack and so it is offline as much aspossible (hence its name). It should preferably only communicate inresponse to an authenticated request. Although any suitable wired orwireless connectivity may be used, the connectivity means is preferablynear field communication (NFC) or other physically activated wirelesscommunication. The device preferably has an infrastructure for securemessaging and storage, such as that described in ISO 7816-4.

Preferably, at least part of the challenge from the server is passedfrom the client to the portable apparatus so that the portable apparatusmay generate all or part of the response. Thus, preferably, the portableapparatus determines the digest for transmission to the server from thedigest of user credentials stored thereon and preferably also from theat least part of the challenge. Most preferably the response is asdescribed above.

In a simple form of the invention, the portable apparatus may comprise asingle set of credentials. This may be appropriate where the apparatusis to be supplied to a user by the operator of a particular server. Thisis likely to occur in situations where a high level of security isrequired, such as for financial transactions and the server operatorwishes to ensure security at the client. In such a scenario, theapparatus may be provided via a secure delivery means and alreadycomprise the user credentials, or part of them. However, it is generallyenvisaged that the invention will be used by a user to store sets ofcredentials for multiple servers (and/or multiple identities belongingto a single user), for example to enable access to multiple web sites towhich the user subscribes—paywall news services, sites of membershiporganisations, shopping sites, etc. Since the portable apparatus storesthe credentials, the user is not restricted to the use of memorablepasswords and will not be tempted to use the same password for multipleservers. The password may be generated, saved to the portable apparatusand forgotten.

Even though the credentials are stored on the portable apparatus in theform of a digest, which makes recovery of the password itselfimpracticable, it is preferred that steps be taken to preventunauthorised use of the apparatus and/or the digest itself. It istherefore preferred that the portable apparatus requires the input of apassword or PIN, e.g. via text input means, or biometric identifier(fingerprint, iris scan, etc.) before the credentials may be used. Suchan input may be required once per session (e.g. on powering up theapparatus) or each time an authentication is required. In most cases itwill be sufficient to require this input before the apparatus can beactivated, but if a still higher lever of security is required, thedigest(s) of the credentials may be stored in encrypted form. Theabove-mentioned inputs or some other input, such as a master password,may be required to perform the decryption.

Preferably, the unique identifier corresponds to the identity of aportable device which communicates with the client computer tofacilitate the authentication protocol. The digest is preferablyprovided to the portable device and stored thereon. The uniqueidentifier may be transmitted to the server in encrypted form,preferably using a public key associated with the server.

As mentioned above, in certain forms of the invention, the password maybe provided for the user. Indeed, in the preferred forms of theinvention, the password of the user is generated at the server and thedigest of the user credentials is generated therefrom at the server andcommunicated to the user.

For example, the OffPAD may first generate a random and preferably largepassword (e.g. 16 bytes or longer) and uses it to create automatically acredential set for the specified realm. This may also include a uniqueID of the OffPAD, though the user could provide a username. Preferablythe credential set automatically generated at the OffPAD is hashed,together with the realm using, for example, SHA-1 or MD5 to produce theHA1 of digest authentication. The HA1 value is stored locally andtransmitted confidentially to the server for registration. The HA1 islinked to the username and realm and the system notifies the user of hisauthorization.

The digest of the users credentials may be transmitted securely to theportable device via the network, e.g. using symmetric or asymmetricencryption or the digest of the users credentials may be communicated tothe user off-line, for example by post, courier or personal delivery.They may be communicated in written form, but it is preferred to use asmart card or other data carrier which may be read by the portableapparatus.

This arrangement is regarded as being inventive in itself and therefore,viewed from another aspect, the invention provides a method ofgenerating and supplying to a client credentials for use in anauthentication protocol to permit the user of a client computer accessto a remote server, the method comprising: transmitting from the clientto the server a unique identifier of the user; at the server, randomlygenerating a password for the user and based on that password generatinga digest for use in the authentication protocol; and providing thedigest to the user.

Preferably, the digest is also based on the unique identifier. Forexample, the unique identifier may be used as the “username” valueduring authentication. Additionally or alternatively, it may be used tocalculate nonce and client nonce values.

The method preferably further comprises preferred features of thepreviously described aspect of the invention.

The invention also extends to a portable apparatus (e.g. an “OffPAD”)for use in the above-described methods. Thus, viewed from a furtheraspect, the invention provides a portable apparatus for enabling a userof a client computer to securely access a remote server via a network byauthenticating the user, the authentication protocol including thetransmission from the client to the server of a response to a challengeby the server; wherein the portable apparatus comprises: means forcommunication with the client computer; and memory for storing in theform of a digest the user credentials required to enable the user to beauthenticated at the server; the portable apparatus being configured toreceive at least part of the challenge and to generate the responsebased on the digest of the user credentials.

The portable apparatus is preferably configured for use in the methodsand preferred forms thereof described above.

The invention also extends to the portable apparatus in combination witha client computer with which it communicates, and also to a systemcomprising a server and the combination of client computer and portabledevice communicating therewith over the network.

From a further aspect, the invention extends to software comprisinginstructions to cause a computing apparatus to carry out the relevantparts of the methods described herein.

Certain embodiments of the invention will now be described, by way ofexample only, and with reference to the accompanying drawings, in which:

FIG. 1 is a diagram illustrating conventional HTTP Digest AccessAuthentication;

FIG. 2 is a schematic diagram of an OffPAD for use with embodiments ofthe invention; and

FIG. 3 is a diagram illustrating HTTP Digest Access Authentication inaccordance with embodiments of the invention.

The conventional HTTP Digest Access Authentication protocol is known tothose skilled in the art and is described in Annex 1 hereto, withreference to FIG. 1, for completeness. The embodiments of the inventionthat will be described with reference to the remaining figures employ aprotocol that, when viewed from the server-side, is identical to theconventional protocol. However, the client-side is significantlymodified and a new registration protocol is provided.

FIG. 2 shows a portable apparatus 1 referred to herein as an “OffPAD”.It comprises a secure housing 2 which encloses internal storage (solidstate memory) 3, processor 4, connectivity means 5 and a touch screen(or screen and other text input means) 6.

The OffPAD is designed to have limited connectivity in order to reduceits vulnerability to attack and so it is offline as much as possible. Itshould only communicate in response to an authenticated request. Theconnectivity means 5 is NFC. The device has an infrastructure for securemessaging and storage such as that described in ISO 7816-4 and accesscontrol is provided by the requirement to enter a PIN code via textinput means 6.

The internal storage contains software, i.e. applications required tooperate the OffPAD, and data in the form of sets of credentialscorresponding to identities that are used to identify the user of theOffPAD when he wishes to access a remote server using his clientcomputer. The software may run passively, i.e. without userintervention, particularly where only a single or a small number ofset(s) of credentials are to be stored by the OffPAD, or where nomanagement or modification of credentials is needed.

The OffPAD communicates with the client using connectivity means 5during digest authentication.

When digest authentication is done using the OffPAD, it handles part ofthe work conventionally done by the user client. Managing identities formultiple users at multiple realms it can either by itself, or byinteraction with the user via the text input means 6, choose whichidentity to use. Authentication can be fully automated in situationswhere only one identity set is applicable, that is, only one user isregistered for the realm in question. The identities are stored securelyon the device. The authentication process will now be described withreference to FIG. 3. Here, the OffPAD 1 is shown in communication withthe client computer 7 which in turn is connected to remote server 8.

The user navigates to the server he wishes to access using the clientcomputer which seeks to access a realm of server 8, by means of clientrequest 9, which issues a challenge (authentication request) to theclient in the conventional manner. This is routed to the OffPAD 1.

During the authentication phase, when calculating the response value fordigest authentication, some of its contents are split in two separatecalculations, HA1 and HA2. These calculations are in themselvesconventional and are as described in Annex 1. HA1 is a digest (hash) ofthe relevant user credentials and the realm being accessed and thereforecomprises both secret and static information. However, in theembodiment, HA1 is stored separately in storage 3 of the OffPAD. Assuch, the embodiment uses only that hash value, without ever exposingthe secret credentials (e.g. the password) in clear text, in the processof response value calculation.

Access to the HA1 values of a user is done as follows: upon authorizedrequest, the HA1 value in question is read from storage 3 on the OffPAD.The HA1 value is then used in the calculation of the response, togetherwith the non-secret, dynamic HA2 whose contents are received from theserver's request. Regardless of the age of HA1, a fresh response valuemay be calculated every time without having to store user credentials inplain text anywhere.

The server validates the response to the challenge in the conventionalmanner, authorising access if it is valid.

Although the embodiment may be used to access a server where a user hasregistered in the conventional manner, in which case the digest of A1(i.e. HA1) is calculated locally, in a variant embodiment, HA1 iscalculated at the server. This overcomes the problem that theregistration phase is not intuitively secure.

To achieve this, the OffPAD first generates a random large password(e.g. 16 bytes) and uses it to create automatically a credential set forthe specified realm. This may include a unique ID of the OffPAD 1,though the user could provide a username. Then, the user's identifier(username) is noted as authorized in the access policy of the systemprotecting the realm at the sever 8. To do this, the credential setautomatically generated at the OffPAD is hashed, together with the realmusing SHA-1 or MD5 to produce the HA1 of digest authentication. The HA1value is stored locally and transmitted confidentially to the server forregistration. The HA1 is linked to the username and realm and the systemnotifies the user of his authorization.

The registration phase in the original digest authentication scheme isdone manually by pointing to a text document containing the authorizedusers in a list of the form username:realm:A1. If a higherauthentication assurance level (AAL) is required, the credential set canbe produced at the server side and securely transferred to the enduser's OffPAD 1 out of band, e.g. using encrypted credentials on RFID(contactless) cards readable by the OffPAD.

Annex 1—HTTP Digest Access Authentication

HTTP Digest Access Authentication is a 1997 web standard forauthenticating a client to a server. Its intended use is on the WorldWide Web, but it is perfectly implementable on local resources, or inany situation where resource access over HTTP should be restricted.Digest authentication was introduced as an extension to the formerstandard basic access authentication which, as noted above is consideredinsecure.

In practice digest authentication is used to enforce an access controlpolicy on a certain realm and the resources it contains. Authorizedaccess to a realm protected by digest authentication requires each userto:

1) be registered with sufficient credentials (user name and password) atthe system enforcing the realm's access control.

2) be able to authenticate himself to the server using the registeredcredentials.

To understand digest authentication, consider this scenario: The userwants to access some web resource at http://example.com/secret/. The/secret/directory has been protected by its owner with digestauthentication, so that only authorized users are approved access.

Trying to access http://example.com/secret/ initiates the followingchallenge/response communication between the user and server, over theHTTP protocol:

1) The client's web browser (user agent) issues a HTTP GEThttp://example.com/secret/

2) Server responds with a 401 Authorization Required status code,indicating to the user that this resource requires him to be authorizedfor access, and that he is currently not authenticated. Along with thestatus code, the server passes a www-authenticate header, containinginformation that can help the system calculate the correct response forthe server.

3) The web browser interprets the 401 status code and prompts the userfor user name and password.

4) A combination of the credentials and information extracted from theincoming www-authenticate header are hashed. They are then passed withanother HTTP GET, now with an appended Authorization header, containingthe response and other values.

5) The server receives the response value—a hash of the user'scredentials and the name of the protection realm. As hashing algorithmsare one-way functions, there is no way for an adversary to simplyextract the passwords from the value. At the server side, thecredentials that were stored locally at the time of registration areused to calculate another hash value by the same rules and algorithm asat the client side. If the server side calculation is equivalent to theone received from the client, the server can conclude that it is certainof the client's identity and validate it against the access policy. Ifthe user is authenticated and authorized, the server responds with a 200OK status code and the contents of the protected resource that the userrequested. If not, he is presented another 401 Authorization Required,and given another try at authenticating.

In addition to cryptographic hash functions, several other securitymechanisms were introduced with Digest Authentication. They aredescribed in the following subsections.

A. Replay Attacks and the Nonce

Basic authentication's big flaw was that the password was minimallyprotected; in effect it could be read by anyone who knew what they werelooking for. After decoding the password, the adversary would be in aposition where he could be falsely authenticated at the remote server,and at any other location the victim had used that same password.Introducing hash functions, however, again only converts the password;though this time in an indecipherable manner. The adversary can nolonger directly deduce the password from the source, but he is free toreuse the values he captures. Also, an exhaustive or dictionary attackon the retrieved password hash is possible. Below is an attack scenariousing the first weakness on a form of Basic authentication that hashesthe credentials instead of encoding them.

1) Alice (the client or victim) logs on to a remote server, andauthenticates using her username Alice and the password Alice1234. Thisproduces the following response value in the Authorization header:

-   -   MD5(“Alice:Alice1234”)=910997b86fbcb903e6b38a015c90746d.

As it is clear to the server that she is in possession of the password,she is authorized, and logged in.

2) Harold (the hacker), who is tapping into the network traffic,collects Alice's MD5 hash. He then tries logging in at the same serveras Alice with an erroneous password. This produces a different MD5 hashthan above.

3) Before passing the erroneous hash to the server, he replaces theincorrect hash value with the one he captured from Alice earlier.

4) Harold has now falsely authenticated himself as Alice, and gainsunauthorized access to Alice's resources.

This is known as a replay attack: the header is replayed to the server,who unwittingly identifies the login attempt as another one from Alice.As the password hash is the same, the perpetrator is approved access.Note that Alice has no way of noticing the attack, as she isexperiencing a passive attack from the adversary, in which he onlyreads. Countering replay attacks is done by introducing another valueinto the communication: the nonce. By its name, the nonce value is anumber used only once, only for one try at authenticating or a verylimited amount of time. The nonce value is created at the server as achallenge to the user. If she is able to respond with the current nonce(and it has not yet been used), she passes the challenge. This way,executing a replay attack must be done before the actual response issent from Alice.

This nonce calculation procedure is suggested in RFC2617:

time-stamp H(time-stamp “:” ETag “:” private-key)

Where H is some hash function (usually MD5), time-stamp is the currenttime at the server, ETag is a fingerprint value unique to the contentsat the location and private-key is a value private to the server. Thesevalues are not thoughtlessly chosen. The time stamp separates theauthentication tries from each other in time and the ETag is used torule out cases where old nonces are reusable due to a site update.Finally, the private key is used for the server to ascertain that theintegrity of the nonce does not change during transmission. Albeit asuggestion, the nonce calculation function above has become a de factostandard; all major web browsers seem to use the same function.

1) Client nonce: The client nonce is another nonce passed from theclient to the server to get the same assurance in the other direction aswell. It is used only in conjunction with the quality of protection(qop) directive. We describe this below.

B. Quality of Protection

Quality of Protection, defined in the qop field, describes what level ofprotection of the digest authentication scheme is used. It is initiallysent from the server as an advertisement of available protectionservices. qop is defined for these values:

1) auth: Used to authenticate the user to the server with username andpassword.

2) auth-int: As above, with additional integrity protection: A hash ofthe entity body8 is hashed into the final response value.

Note that qop is not a requirement but a recommendation in DigestAuthentication. RFC2617 is backwards compatible with the initialversion, RFC2069.

C. Calculating the Response Value

The response value is calculated by the user as an answer to theserver's authentication challenge (the www-Authenticate header). Thevalue is the result of hashing two independent parts. The first, calledHA1 is a hash of the realm and the user's credentials (i.e. A1) and thesecond, HA2, is a hash of time- and site-specific information (i.e. A2).Consequently, one can distinguish HA1 and HA2 as the secret andnon-secret, or static and dynamic components of response respectively.

1) HA1:The contents of HA1 are dependent on the algorithm provided. IfMD5 or no value is defined in the algorithm field, only the usercredentials are used:

HA1=MD5(username:realm:password)

If the server requires HA1 to have time limited validity(algorithm==“MD5-sess” or similar), nonce and cnonce (client nonce)values are also applied:

HA1=MD5(MD5(username:realm:password):nonce:cnonce)

Notice that the MD5-sess response contains the default response value.The lifetime of the MD5-sess version of HA1 is dependent on the lifetimeof the nonces, as these are wrapped in

2) HA2: When calculating the HA2 value, the qop field is taken intoconsideration. HA2 is defined for qop-values “auth” and “auth-int”, andnon-present qop for backwards compatibility with RFC2069. If qop==“auth”or nonpresent:

A2=MD5(method:uri)

Where method is the HTTP request method that was used. It can be any ofthe methods described in the HTTP standards, such as GET, POST, etc. AllHTTP Request methods are defined in the HTTP 1.1 RFC[4]. Ifqop==“auth-int”:

A2=MD5(method:uri:MD5(entity-body))

3) response: When both HA1 and HA2 have been calculated, the responsevalue is finalized depending on whether qop is set: If qop is set(either qop==“auth” or qop==“authint”)

response=MD5(A1:nonce:nc:cnonce:qop:A2)

Where nc is an eight digit nonce counter incrementing on every attempt.If qop is not set, the response value must be backwards compatible withRFC2069 using only the nonce value:

response=MD5(HA1:nonce:HA2)

1. A method for enabling a user of a client computer to securely accessa remote server via a network, which is preferably the Internet, byauthenticating the user, the method comprising: providing a portableapparatus to the user which may communicate with the client computer;storing on the portable apparatus user credentials required to enablethe user to be authenticated at the server; performing an authenticationprotocol between the client and the server; wherein: the authenticationprotocol includes the transmission to the server of a digest based atleast partially on the user credentials; and the user credentials arestored on the portable apparatus in the form of a digest.
 2. A method asclaimed in claim 1, wherein the credentials comprise the username,password of the user and realm of the server that is to be accessed. 3.A method as claimed in claim 1 or 2, wherein the protocol is HTTP DigestAccess Authentication.
 4. A method as claimed in any preceding claim,wherein the network is the Internet.
 5. A method as claimed in anypreceding claim, wherein the portable device communicates with theclient computer only to facilitate authentication of the user.
 6. Amethod as claimed in any preceding claim, wherein the digest istransmitted in response to a challenge from the server.
 7. A method asclaimed in claim 6, wherein at least part of the challenge from theserver is passed via the client to the portable apparatus.
 8. A methodas claimed in claim 7, wherein the portable device determines the digestfor transmission to the server from the digest of user credentialsstored thereon and preferably also from the at least part of thechallenge.
 9. A method as claimed in any preceding claim, wherein theportable device holds a plurality of sets of user credentialscorresponding to different identities and/or servers.
 10. A method asclaimed in any preceding claim, wherein the digest(s) of the credentialsis/are stored in encrypted form.
 11. A method as claimed in anypreceding claim, wherein the portable apparatus requires the input of apassword, PIN or biometric identifier before the credentials may be usedor modified.
 12. A method as claimed in any preceding claim, wherein thepassword of the user is generated at the server and the digest of theusers credentials is generated therefrom at the server and communicatedto the user.
 13. A method as claimed in claim 12, wherein the digest ofthe users credentials is transmitted securely to the portable device viathe network.
 14. A method as claimed in claim 12, wherein the digest ofthe users credentials is communicated to the user off-line.
 15. Aportable apparatus for enabling a user of a client computer to securelyaccess a remote server via a network, which is preferably the Internet,by authenticating the user, the authentication protocol including thetransmission from the client to the server of a response to a challengeby the server; wherein the portable apparatus comprises: means forcommunication with the client computer; and memory for storing in theform of a digest the user credentials required to enable the user to beauthenticated at the server; the portable apparatus being configured toreceive at least part of the challenge and to generate the responsebased on the digest of the user credentials.
 16. A portable apparatus asclaimed in claim 15 configured for use in the method of any of claims 1to
 14. 17. A method of generating and supplying to a client credentialsfor use in an authentication protocol to permit the user of a clientcomputer access to a remote server, the method comprising: transmittingfrom the client to the server a unique identifier of the user; at theserver, randomly generating a password for the user and based on thatpassword generating a digest for use in the authentication protocol;providing the digest to the user.
 18. A method as claimed in claim 17,wherein the digest is also based on the unique identifier.
 19. A methodas claimed in claim 18, wherein the unique identifier is used as the“username” and/or is used to calculate nonce and/ or client noncevalues.
 20. A method as claimed in claim 17, 18 or 19, wherein theunique identifier corresponds to the identity of a portable device whichcommunicates with the client computer to facilitate the authenticationprotocol.
 21. A method as claimed in claim 20, wherein the digest isprovided to the portable device and stored thereon.
 22. A method asclaimed in any of claims 17, to 21, wherein the unique identifier istransmitted to the server in encrypted form, preferably using a publickey associated with the server.